Skip to content

Wifi based heuristics#1042

Open
jacklund wants to merge 8 commits into
EFForg:mainfrom
jacklund:wifi-based-heuristics
Open

Wifi based heuristics#1042
jacklund wants to merge 8 commits into
EFForg:mainfrom
jacklund:wifi-based-heuristics

Conversation

@jacklund

@jacklund jacklund commented May 18, 2026

Copy link
Copy Markdown
Contributor

First pass at a solution for issue #1000.

Some notes:

  • I've managed to shoehorn my code into the analysis flow, although whether it's in the best place I'll leave up to y'all. I've added a WifiOUIAnalyzer type, which implements Analyzer, and which gets added to the analyzer harness by default (and is configurable). I've also added the configured OUIs to the AnalyzerConfig which felt weird, since everything else on that are booleans, but there didn't seem to be a better place to put that and still have it available in the Harness code.

  • I've added a config line to specify the target OUIs as a comma-separated list of strings. I don't currently validate the OUIs (which should be done), because I'm not certain that's the best way to specify them. At some point there should probably be lists of well-known OUIs for specific types of target devices (similar to what Colonel Panic does in his OUI-spy apps), but until we have those lists, this might have to do.

  • I've also marked a OUI match as a HIGH event type, which might not be what is wanted here, it just seemed like a good place to start.

  • There's some code duplicated from DiagTask::process_container where I send the information to the notification channel and the display, which is not great, but I figured that some refactoring of the analysis flow to make this code fit better might make that go away anyway.

  • Also, I'm using my fork of wifi-station for this PR - I have a PR pending on that repo which will add the BSSID to the list of items returned when scanning. Hopefully when/if that PR is merged, we can put that back.

Pull Request Checklist

  • The Rayhunter team has recently expressed interest in reviewing a PR for this.
    • If not, this PR may be closed due our limited resources and need to prioritize how we spend them.
  • Added or updated any documentation as needed to support the changes in this PR.
  • Code has been linted and run through cargo fmt.
  • If any new functionality has been added, unit tests were also added.
  • CONTRIBUTING.md has been read.
  • Your pull request is fewer than ~400 lines of code.

You must check one of:

  • [ x No generative AI (including LLMs) tools were used to create this PR.
  • Generative AI was used to create this PR. I certify that I have read and understand the code, and that all comments and descriptions were authored by myself and are not the product of generative AI.

@cooperq cooperq self-requested a review May 19, 2026 17:43
@cooperq cooperq self-assigned this May 19, 2026
@jacklund jacklund force-pushed the wifi-based-heuristics branch from b981cc8 to 08f07b6 Compare May 23, 2026 21:22
@jacklund

jacklund commented May 24, 2026

Copy link
Copy Markdown
Contributor Author

Rebased against upstream main

@jacklund jacklund force-pushed the wifi-based-heuristics branch from 08f07b6 to 2233390 Compare May 29, 2026 00:40
jacklund added 8 commits May 31, 2026 10:50
@jacklund
First pass towards adding wifi scan for OUIs
142f8bd 
EFForg#1000
Added ability to scan wifi networks (with a change to the wifi-station
library, which I will PR once I get this working). Trying to integrate
it into the analysis setup didn't work well, because that's pretty much
only set up for packet analysis, so I'm instead sending the change to
the display state directly from the wifi analysis function, which
probably isn't really what's needed.
@jacklund
Try to hook wifi oui analyzer into analysis harness
e1a767d
@jacklund
Got wifi oui analyzer working!
559b35b
@jacklund
Clippy & fmt
51d53da
@jacklund
Add test
d5f1ba2
@jacklund
npm lint
e1423f4
@jacklund
Add wifi_ouis to TS AnalyzerConfig
34e5875
@jacklund
cargo fmt
4eabcd7
@jacklund jacklund force-pushed the wifi-based-heuristics branch from 4be8c5b to 4eabcd7 Compare May 31, 2026 15:50
@cooperq

cooperq commented Jun 4, 2026

Copy link
Copy Markdown
Collaborator

@jacklund sorry for the delay on reviewing this I'm having a look at it now

@cooperq

cooperq commented Jun 5, 2026

Copy link
Copy Markdown
Collaborator

I like the direction of your approach here. A few issues:

  1. alerts are reflected in the screen UI and the notifications but not in the web UI. We probably want to preserve the alerts and the OUI that triggered them. but we also want to update the web UI when we alert on an OUI. One way to do this would be to write it to the ndjson file but I think those currently get erased when we do a rescan. Another way would be to write it to its own separate wifi log which might be a better idea. It would be cool if we could write something to the pcap somehow from this but I will consider that a stretch goal for now.

  2. the list of mac addresses the wifi client sees is very limited right now, I'm not really sure whats up with this but I supsect its stuck on one channel and perhaps not channel hopping? I will have to look into this.

  3. Obviously this needs more documentation :) also the alert level for this should probably be low or informational for now as this is only useful in conjunction with other alerts.

@cooperq

cooperq commented Jun 5, 2026

Copy link
Copy Markdown
Collaborator

One of the main imsi catcher manufacturers is keyw corporation who has an unusual OUI of https://maclookup.app/macaddress/70b3d57cb 70:b3:d5:7c:b

It would be cool to be able to match against an oui like this that is >3 bytes but also the half byte at the end (crazy stuff I know)

Also we should have a sane default list of OUIs. I can provide this.

cooperq
cooperq requested changes Jun 5, 2026
View reviewed changes

@cooperq cooperq left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please address the changes in my above comments.

@jacklund

jacklund commented Jun 5, 2026

Copy link
Copy Markdown
Contributor Author

@jacklund sorry for the delay on reviewing this I'm having a look at it now

No worries, I know y'all are slammed.

@jacklund

jacklund commented Jun 5, 2026

Copy link
Copy Markdown
Contributor Author

One of the main imsi catcher manufacturers is keyw corporation who has an unusual OUI of https://maclookup.app/macaddress/70b3d57cb 70:b3:d5:7c:b

Wow, that's crazy.

It would be cool to be able to match against an oui like this that is >3 bytes but also the half byte at the end (crazy stuff I know)

Well, right now I do a startswith() (IIRC) for the OUI matching. I was considering doing some more stuff to restrict it to 3 bytes, but I guess leaving it for now makes sense for stuff like that.

Also we should have a sane default list of OUIs. I can provide this.

👍

@jacklund

jacklund commented Jun 7, 2026

Copy link
Copy Markdown
Contributor Author

I like the direction of your approach here. A few issues:

1. alerts are reflected in the screen UI and the notifications but not in the web UI. We probably want to preserve the alerts and the OUI that triggered them. but we also want to update the web UI when we alert on an OUI. One way to do this would be to write it to the ndjson file but I think those currently get erased when we do a rescan. Another way would be to write it to its own separate wifi log which might be a better idea. It would be cool if we could write something to the pcap somehow from this but I will consider that a stretch goal for now.

Sounds good. I'm going to have to use a separate logger in that case, not a big deal, since y'all redirect the default logging from stdout to the rayhunter logs. I'll probably use whatever's simplest for now, although if you have a preference for a particular logger, I can use that. I'll also add something to be able to look at the wifi logs similar to what's done in the web UI for the rayhunter logs.

I think to be really useful, we'd need to include both the OUI and the manufacturer in the alert, which means we'd need to configure it with both (i.e. my simple config of a list of OUIs probably won't cut it). I'll probably change that to a list of manufacturer => list of OUIs, unless you think that's overkill.

2. the list of mac addresses the wifi client sees is very limited right now, I'm not really sure whats up with this but I supsect its stuck on one channel and perhaps not channel hopping? I will have to look into this.

Hadn't noticed that. I can look at that as well.

3. Obviously this needs more documentation :) also the alert level for this should probably be low or informational for now as this is only useful in conjunction with other alerts.

Yep, I figured I'd wait until we settled on a set of stable features before tackling documenting it, but I can probably start with some of what we've got now. I'll also change the alert level.

Thanks for the feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cooperq cooperq cooperq requested changes

Requested changes must be addressed to merge this pull request.

Assignees

@cooperq cooperq

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@jacklund @cooperq